133 - feefilter message
BIP: 133 source Layer: Peer Services Title: feefilter message Author: Alex Morcos Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0133 Status: Final Type: Standards Track Created: 2016-02-13 License: PD Table of ContentsAbstractMotivationSpecificationConsiderationsBackward compatibilityImplementationCopyright Abstract Add a new message, "feefilter", which serves to instruct peers not to send "inv"'s to the node for transactions with fees below the specified fee rate. Motivation The concept of a limited mempool was introduced in Bitcoin Core 0.12 to provide protection against attacks or spam transactions of low fees that are not being mined. A reject filter was also introduced to help prevent repeated requests for the same transaction that might have been recently rejected for insufficient fee. These methods help keep resource utilization on a node from getting out of control. However, there are limitations to the ef...
90 - Buried Deployments
BIP: 90 source Title: Buried Deployments Author: Suhas Daftuar Comments-Summary: Mostly Recommended for implementation, with some Discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0090 Status: Final Type: Informational Created: 2016-11-08 License: PD Table of ContentsAbstractMotivationConsiderationsSpecificationImplementationReferencesAcknowledgementsCopyright Abstract Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers. Now that the chain has long since passed the blocks at which those consensus rules have triggered, we can (as a simplification) replace the trigger mechanism by caching the block heights at which those consensus rules became enforced. Motivation BIPs 34, 65 and 66 were deployed on mainnet using miner signaling using block version numbers. In short, new consensus rules were proposed for use in blocks with a higher version number (N+1) than the prevailing block versio...